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This Application claims the benefit of priority from U.S. Provisional Application 
5 Serial No. 60/411,330, entitled "ELECTRONIC BANKING SYSTEM", filed on 
September 16, 2002. 

Field of Invention 

The present invention is related generally to banking, and more particularly to 
10 electronic banking systems for facilitating the processing of bank transactions. 

Background of the Invention 

Current systems for posting banking or transaction orders (e.g., fund 
transfers, payment processing and statement and report requests) to banking 

15 institutions from customers generally rely on antiquated and manual methods that 
are time-consuming, inefficient and prone to error and loss. Such systems often rely 
on paper-based methods, which involve human intervention and physical delivery of 
paper documents each of which contribute to slow processing rate and undue delay. 
Parties to a banking transaction must often wait a considerable amount of time for a 

20 bank to complete a particular transaction. For larger organizations conducting 
numerous local and international banking transactions each day, the inefficiencies of 
current systems become more apparent. 
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For example, in a typical payment transaction between a vendor and a large 
customer, the vendor prepares and submits an Invoice for delivery to the customer. 
The customer receives the invoice and forwards it to the corresponding originating 
department, which originated the dealings with the vendor. The originating 

5 department reviews and approves the invoice for payment The approved invoice is 
then forwarded to accounts payable where a check is prepared. Since the system is 
a paper-based process, it relies significantly on internal mail correspondences and 
can take about four weeks to complete. The check is forwarded to an appropriate 
administrator for verification and signature. The check is then delivered to the 

10 vendor. The vendor receiving the check subsequently presents it to the bank for 
payment This final portion of the transaction involves further time to process (i.e., 
from one hour to three days), requires human intervention and a retail banking 
system to complete the transaction. Although the customer may receive a bank 
statement on a periodic basis or on a real time basis via electronic means (e.g., 

15 Internet), it may require twenty to thirty days to reconcile the payment with the 
invoice of the previous month due to the inefficient check presentment and clearing 
process. If the check is lost during the process, the process is repeated. 

Accordingly, there is a need to provide an electronic banking system which 
20 can automatically process banking orders issued by a customer for automatically 
processing monetary transactions, such as making electronic payments to bank 
accounts or beneficiaries (i.e., payees) or transferring money between accounts, with 
minimal delay or human intervention, while utilizing existing hardware, software and 
communication components. There is a further need for an electronic banking 
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system, which provides accurate real-time assessment of the outstanding liabilities 
involving accounts with multiple banks, and thus shortening the time needed for 
reconciling the accounts. 



5 Summary of the Invention 

The present invention relates to an electronic banking system, which can be 
used to provide an efficient automated interface between a bank and a customer, 
wherein the customer can from their location or facility electronically issue a bank 
order to one of multiple member banks of the system to initiate the automated 

10 processing of the requested monetary transaction. The electronic banking system of 
the present invention can readily be adapted for use with existing hardware, software 
and communication components. The electronic banking system is further 
compatible for operation with a range of proprietary retail banking systems through a 
global computer network. In one particular embodiment of the present invention, 

15 there is provided an electronic banking system for automatically processing 
monetary transactions including transfer of funds into appropriate monetary accounts 
with minimal delay and human intervention over a local or global computer network 
(such as the Internet). 



20 In one aspect of the present invention, there is provided an electronic banking 

system, which comprises: 

a host bank server adapted for receiving a transaction request and processing 
the transaction request; 

means for initiating the transaction request in an automated operation; 
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a global computer network in data communication between the host bank 
server and the initiating means, for transmitting the transaction request from the 
initiating means to the host bank server; and 

means for interfacing the initiating means to the host bank server and for 
5 converting the transaction request into a readable form compatible with the host 
bank server and establishing a secure data communication connection 
therebetween. 

Brief Description of the Drawings 

10 Various embodiments of the invention are described in detail below with 

reference to the drawings, in which like items are identified by the same reference 
designation, wherein: 

Figure 1A is a schematic diagram illustrating a payment process as one of the 
15 applications facilitated by the implementation of an electronic banking system in 
accordance with the present invention; 

Figure 1B is a schematic diagram of an electronic banking system in 
accordance with an embodiment of the present invention; 

20 

Figure 2 is a schematic diagram of the overall architecture of the electronic 
banking system for one embodiment of the present invention; 
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Figures 3A through 3F represent in combination a flowchart detailing the 
operational steps of the electronic banking system in payment mode for an 
embodiment of the present invention; 

5 Figure 4 is a flowchart detailing the operational steps of the electronic banking 

system in statement and reconciliation mode for another embodiment of the present 
invention; and 

Figure 5 is a flowchart detailing the operational steps of the electronic banking 
10 system in statement display mode for yet another embodiment of the present 
invention. 

Detailed Description of the Invention 

The present invention is directed to an electronic banking system and a 
15 method of processing monetary transactions. In one mode of operation, the 
electronic banking system of the present invention is adapted for automatically 
processing monetary transactions and making appropriate fund transfers (i.e., 
payments) into financial accounts in a rapid manner with minimal human 
intervention. The electronic banking system of the present invention is further 
20 adapted to utilize a global computer network such as the Internet, and existing 
hardware and software components, for example. The present invention can readily 
be implemented in collaboration with monetary data processing entities including, but 
not limited to, banks, payment processing centers, financial clearinghouses and the 
like. 
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The automated feature of the present invention provides a user, such as a 
large organization having numerous local and international monetary transactions, 
with the capability to transact business with banking systems in synchronous mode. 
5 This enhances processing times and allows the user to automatically reconcile its 
payment system with the account records of the banking system in a rapid real-time 
manner with minimal human intervention. 

The primary end users of the system include the treasury users who will 
10 access the system to secure approval of the transactions prior to implementing 
processing. The treasury users are typically part of the group in the large 
organization responsible for the management of the organization's worldwide real 
and financial assets, liabilities and risks associated with revenue, investment, debt, 
foreign exchange, credit and insurance. Thus, the system of the present invention 
15 provides a useful tool for enabling the treasury users to maintain and manage the 
daily financially operations of the organization in an integrated and automated 
manner. 

In one embodiment of the present invention, the electronic banking system 
20 includes three main components: a core transaction processing component for 
generating and initiating monetary transactions, a core interface component for 
communicating with a bank server via the Internet, and a bank interface component, 
all of which cooperate to form a communication link with the core interface 
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component while authenticating, validating, transacting and confirming transactions 
for the present system. 



The present invention in its various embodiments can provide the following 

5 functions: 

1 . Electronic fund transfers to third parties; 

2. Electronic fund transfers between common accounts in same bank; 

3. Electronic fund transfers between common accounts in different banks; 

4. General type payments; 

10 5. Automatic end of day electronic bank statement retrieval and 

reconciliation; 

6. Generation of a facsimile payment advice notification to third parties; 

7. Generation of a facsimile anticipated payment notification (Sales 
Revenue Receivables) to recipient Bank; 

15 8. Automated telex functionality to provide backup for the system of the 

present invention; 

9. Generation of cash position reports to indicate customer's financial 
liability; and 

10. Online retrieval of account balance at any of the member banks directly 
20 integrated through the system of the present invention. 

With reference to Figure 1A, a payment process 220 is shown representing 
one of several applications facilitated by the present invention. The payment 
process 220 begins with step 222 in which a beneficiary or payee prepares and 
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submits an invoice for payment to a customer 230 such as an individual, a company 
or large organization. Assuming the customer 230 is a large enough entity to include 
purchasing and accounting departments, in step 224, the invoice is delivered to a 
receiving department of the customer (e.g., purchasing) responsible for reviewing the 

5 invoice and directing it to the proper department for further processing and approval. 
The receiving department inputs the invoice information into a business enterprise or 
workflow software system where it is conveyed to the proper parties for processing. 
The invoice information is verified, electronically captured and approved for payment 
using the electronic workflow approval process, which is coordinated between the 

10 Accounts payable department and the originating department which initiated the 
work. In step 226, the invoice is delivered to the originating department for their 
review and approval. In step 228, the invoice approval is forwarded to the accounts 
payable where an electronic payment is prepared in the form of an electronic 
payment instruction. Steps 224 through 228 are implemented internal within the 

15 customer 230 typically via the work flow approval process. In step 232, the customer 
230 forwards the electronic payment instruction to the bank via a computer network. 
The bank 232 then proceeds to process the information and make payment as 
requested by the customer 230. Simultaneously, in step 234, as the payment 
instruction is sent to the bank 232, a facsimile notification is forwarded to the 

20 beneficiary 222 to confirm that the monetary transaction request has been forwarded 
to the bank. The monetary transaction may have been made in any of a number of 
ways, such as by electronically transferring money from the customer's account to a 
bank account of the beneficiary, or by sending a check to the beneficiary. 
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With reference to Figure 1B, there is shown an electronic banking system in 
accordance with one embodiment of the present invention, and indicated generally 
by the reference numeral 10. The system 10 includes in series connection a core 
transaction component 12 which can be a computer server operated by a customer 

s of the banking system; a core interface component 14 in communication with the 
core transaction component 12, which can in certain applications be supported by 
the same computer server providing the core transaction component 12, or by a 
different computer server; a global computer network 16 (e.g., the Internet); and a 
bank interface component 18 supported by a bank server 20 operated by the 

10 customer's bank. The bank interface component 18 is in communication with the 
core interface component 14 via the global computer network 16. Optionally, the 
system 10 can further include a beneficiary server 22 connected to the global 
computer network 16 for communicating with the customer. The core transaction 
component 12, and the core interface component 14 are installed in the customer's 

15 facility. 

The core transaction component 12 forms part of the intranetwork system 
accessible to the customer, and is programmed with a enterprise-based software 
selected from any standard business software used by organizations for supporting 
20 and facilitating collaborative operations in a paperless environment Such software 
can include, but is not limited to, SAP® R/3® Enterprise ERP available from SAP AG 
of Germany. Although the electronic banking system of the present invention is 
shown and described as being programmed with SAP® software and application 
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modules, the present invention is not limited to such software programs, and can be 
modified by substituting other software known in the art 

Once a cash management transaction is reviewed and approved by the user 

5 or a designated approval officer of the customer, the core transaction component 12 
is programmed to automatically generate an electronic transaction order or payment 
instruction, which is automatically processed without further human intervention. 
The generated transaction order is forwarded to the core interface component 14 via 
data communication link 24. The core interface component 14 prepares the 

10 transaction order for transmission (via data communication link 26) over the global 
computer network 16 to the appropriate bank server 20. The core interface 
component 14 facilitates communication through the global computer network 16 
between the core transaction component 12 and the corresponding bank server 20. 
The transaction order is transmitted over the global computer network 16 and is 

15 received by the bank interface component 18, which can, for example, be a 
dedicated computer or part of a computer server providing bank server 20 and is 
programmed to authenticate, validate, transact and confirm the transactions 
contained within the transaction order. The bank interface component 18 is 
configured for operation with the particular retail banking system of the bank server 

20 20. The bank interface component 18 prepares the transaction order into a form 
specific to the retail banking system of the bank server 20. Once the bank server 20 
receives the transaction order, the instruction contained in the order is carried out 
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Referring to Figure 2, the system 10 is shown in greater detail for one 
embodiment of the present invention. The system 10 comprises an intranet zone 
13, an interface zone 15, a firewall zone 17 and a global computer network zone 19. 
The intranet zone 13 generally comprises a dedicated local server 21 programmed 

5 with a enterprise business software system such as, for example, SAP® R/3® an 
integrated customizable core software system programmed for supporting 
application modules such as SAP® Treasury Module (SAP-TR) which is a subset of 
SAP® Financial Accounting Module (SAP Fl). Among other functions, the local 
server 21 performs the operation of the core transaction component 12 in the 

10 present invention. The local server 21 is in communication with at least one work 
station or client computer 32 via a communication link 23 for enabling access to 
authorized users such as designated personnel of the customer. The client or 
customer computer 32 supports graphical user interface (GUI) software such as, for 
example, SAP® GUI Software Version 4.6D. 

15 

The intranet zone 13 further includes a core transaction database memory 34 
connected to the local server 21 for providing storage and retrieval means for data 
processed by the local server 21. The core transaction database memory 34 is 
loaded with a suitable database software such as, for example, Oracle® 5.7.3. 

20 

The interface zone 15 comprises an interface server 25 (provides the 
functions of core interface component 14), which is connected to the local server 21 
via a communication link 24 and a firewall 38 established between the local server 
21 and the interface server 25. The firewall 38 functions to isolate the customer's 
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intranet zone from the interface zone. Its primary function is to secure data traffic to 
the interface zone and servers to authorized access by corresponding systems and 
users. The interface server 25 is programmed with open interface software for 
implementing communication over the global computer network 16, the Internet in 

5 this example, between the core transaction component 12 and the bank server 20. 
In the preferred embodiment of the invention, the open interface software is 
developed from SAP® Business Connector, as illustrated in flowcharts described 
below. The interface server 25 implementing SAP® Business Connector 
communicates with the local server 21 implementing SAP® R/3 system through 

10 Remote Function Calls (RFC). The interface server 25 converts all RFC formatted 
communications from the core transaction component 12 on the local server 21 into 
extensible markup language (XML). In the present embodiment, hypertext transfer 
protocol (HTTP/HTTPS) format is used for communication through the global 
computer network 16. The interface zone 15 is maintained separate from the global 

15 computer network 16 via the firewall zone 17 comprising a pair of firewalls 40 and 
42, respectively. The interface server 25 is electronically connected to the global 
computer network 16 via a communication link 26 extending through the firewalls 40 
and 42, respectively. Data transmitted from the interface server 25 is delivered 
through the global computer network 16 to the bank server 20 via a communication 

20 link 28. 

The core interface component 14 further includes a core interface database 
memory 36 connected to the interface server 25. The core interface database 36 is 
similar to the core transaction database memory 34, and is adapted to provide a 
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storage and retrieval means for all operations associated with the core interface 
component 14. The core interface database memory 36 is preferably established 
behind the firewall 38 on the same side as the intranet computer zone 13, as shown 
in Figure 2. 

5 

In the present invention, the core transaction component 12 generates 
monetary transaction orders to the appropriate bank server(s) 20 at a customer's 
bank or banks for conducting monetary transactions, such as making payments or 
managing cash in the customer's bank accounts). Each of the monetary transaction 

10 orders is generated by the SAP ® R/3 FI-TR module, in this example, of the core 
transaction component 12. The transaction orders are prepared in the form of 
Intermediary documents (IDOC). The IDOCs are forwarded to the interface server 
25 where they are converted into XML, and then forwarded to a predesignated bank 
server 20 at the customer's bank. The predesignated bank server 20 receives the 

15 XML, and the bank interface component 18 reformats the XML documents into a 
format suitable for processing by the bank server 20. 

Referring to Figure 3A, a flowchart is shown to illustrate the payment mode of 
the system 10 in accordance with the principles of the present invention. In initiating 
20 payment, the core transaction component 12 automatically selects transactions (e.g., 
vendor invoices and employee payments) for payment through execution of a 
payment program (i.e., transactions F110 and F111 in SAP®), in this example. The 
algorithm of the system 10 begins in step 50 with the retrieval from the core 
transaction database 34 of parameters for preparing a payment proposal or 
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transaction order by the payment program. Examples of parameters for the payment 
proposal can include typical payment transaction parameters such as, for example, 
posting date (i.e., date on which the payable has been approved for payment), next 
payment run on date (i.e., posting data of the next payment run which is used to 
5 assess the due date of payables), company code (i.e., list of company codes or 
company code intervals that are to be processed together), payment method (e.g., 
check, bill of exchange, and bank transfer abroad) and vendor/customer accounts 
(i.e., range of vendor/customer accounts to be taken into consideration). 

10 in step 52, the core transaction component 12 generates a transaction 

proposal to allow the user to view all outgoing transaction orders including payments 
that the core transaction component 12 will process. This allows the user via 
computer 32 to implement an initial crosscheck before actually posting the 
transactions for payment The algorithm proceeds to step 54 where the payment 

15 program is executed by the core transaction component 12 to generate a payment 
document or instrument in preparation for release. In step 56, the algorithm 
determines the proper format of the payment document or instrument including 
arrangement and selection of the parameters based on the corresponding payment 
methods using SAP® R/3 programs such as "ZFR00440" for USD (U.S. Dollar) 

20 check payments, "RFF0EDI1 D for electronic fund transfer (EFT) payments and the 
like, for example. 

The payment document is generated in the form of an intermediary document 
(I DOC) and released to the core interlace component 14 in step 58. In one example, 

14 
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for EFT payments, the payment program generates two types of documents 
"PAYEXT" IDOCs and "EUPEXR" IDOCs. Each PAYEXT IDOC contains the 
payment information for one payee per bank. The EUPEXR IDOC is a reference 
IDOC generated for each bank and contains all the summary information of the 

5 payment instruments released to the corresponding host bank with a list of the 
PAYEXT IDOC numbers. In SAP® R/3, for this example, the IDOCs are delivered to 
the core interface component 14 via a remote function call (RFC) Destination Port 
As soon as the IDOCs are delivered in step 60, the core transaction component 14 
updates the IDOC statuses to "03" with a message "Data passed to port OK" 

10 indicating that the data has passed correctly to the port, in this example. 

The IDOCs received by the core interface component 14 are stored and 
arranged in a RFC queue in step 62. The EUPEXR IDOCs are received and the 
summary information along with PAYEXT IDOC numbers are mapped and stored as 
15 tables referred herein as T_BC_PAYMENT_REFERENCE and 
T_BC_PAYMENT_REFERENCE _DETAIL. 

In step 64, the algorithm checks to determine if the communication link 24 to 
core interface component 14 is active. If the server 25 of the core interface 
20 component 14 is down or inactive, SAP® R/3 queues all IDOCs in the RFC queue 
until it is up again. The queue is configured such that pending IDOCs are sent again 
to the RFC port every minute until the transmission is successful or the number of 
tries reaches 999 times. For each transmission, the number of retries is increased or 
incremented by one in step 66. The algorithm queries whether the number of tries is 
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greater than 999 in step 68. If the query is "No," the algorithm proceeds to step 70 
wherein the IDOCs are resubmitted to the RFC queue. Otherwise, the algorithm 
proceeds to step 72 wherein the SAP® monitoring personnel are advised of the 
connection problem to allow troubleshooting to be initiated. In step 74, the 

5 monitoring personnel resolves the connection problem and proceeds to step 70 for 
resubmission. The SAP® monitoring personnel are generally composed of 
employees of the customer and are authorized by the customer to monitor the 
systems, servers, components and processes forming part of the system of the 
present invention including both the hardware and software aspects thereof. The 

10 monitoring personnel are prepared to implement the appropriate actions to correct or 
troubleshoot any irregularities that may arise during operation. 

If the connection is determined to be active in step 64, the algorithm proceeds 
to step 76 of Figure 3B. 

15 

In step 76 of Figure 3B, the core interface component 14 receiving the 
PAYEXT IDOCs with payment information and maps the I DOC parameter fields to 
appropriate variables. In step 78, the core interface component 14, that is interface 
server 25, is programmed to store the IDOCs in the core interface database memory 
20 36 also referred as an eBanking DB (database) in the form of a database table 
referred herein as T_BC_PAYMENT_TRANSACTION. Next, in step 80, the core 
interface component 12 of the local server 21, is programmed to, update the IDOC 
statuses in the core transaction component 12 of the local server 25 to "06" with a 
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message Translation OK" by using a SAP® RFC call to the core interface 
component 14 (interface server 25, in this example). 



In step 82, the core interface component 14 formats the IDOCs into "MT100" 
5 instructions (i.e., Customer Transfer) which complies with the standard format 
implemented by the Society for Worldwide Interbank Communication. The 
generated MT100 instructions are then compiled in step 84 into a transaction 
document formatted in extensible markup language (XML). This action is 
accomplished by retrieving all payment instructions from the 
10 T_BC_PAYMENT TRANSACTION table for all IDOC numbers matching the 
information received through the reference IDOC (i.e., EUREXR IDOC). This 
process is executed to compile payment instructions according to the host bank for 
subsequent transmission and posting as a single document to the corresponding 
host bank server 20. The maximum number of payment instructions per transaction 
15 document depends on the host bank. The particular requirements for proper 
preparation and delivery of the transaction document for each bank are stored in a 
configuration file referred herein as an EBANKING.CNF configuration file. 

The transaction documents formatted into SWIFT MT100 (SWIFT is for 
20 "Society for Worldwide Interbank Communication) and wrapped around 
corresponding XML tags await delivery to the host bank server 20. In step 86, the 
bank specific parameters or requirements are retrieved from the EBANKING.CNF 
configuration file. In step 88, the banking specific parameters are used to prepare all 
the transaction documents with a digitally signed certificate using a specific 
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commercially available hashing algorithm. The certificate is used to authenticate or 
digitally sign the document for security purposes prior to delivery. Host bank servers 
20 use the digitally signed certificates to verity the authenticity and to ensure that the 
information contained in the transaction document was not altered during 
5 transmission. The algorithm creates a digital signature for the XML transaction 
document using the bank specific parameters contained in the EBANKING.CNF 
configuration file. 

In step 90, the core interface component 14 establishes a secure connection 
10 to a particular host bank server 20. This is accomplished by setting up a secure 
socket layer (SSL) session. The digitally signed certificate of the transaction 
document along with a root certificate certification path is used to initiate the session. 
The algorithm determines whether a successful connection was established in step 
92. If the connection is not established, the algorithm proceeds to step 94. The core 
15 interface component 14 stores the transaction document along with the bank specific 
parameters in the core interface database memory 36 in a database table referred 
herein as T_BC_FAILED_SERVICE. The table logs all failures including the core 
interface component services. In step 96, the algorithm initiates automatic retry of 
the delivery of the transaction document. The retry of the tailed services is made 
20 about every three minutes, in this example. 

The algorithm proceeds to query step 98 to determine whether the number of 
retries is greater than three. Continuous failure to establish connection email 
notification is sent to a technical support and business team for appropriate 
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corrective action. A report with transaction code "ZF0642" also referred to as a 
payment status tool, is prepared for the business team or treasury users to view the 
statuses of all payment instructions released by the core transaction component 12. 
Options are provided where the business team can retry transmission or generate 
5 automated telex/facsimile as contingency methods for posting the transaction 
documents to the corresponding bank. 

The contingency plan or backup options to send payment instruction to the 
bank can be used in the event that the core interface component 14 or the host bank 
10 server 20 are unable to process the payment instruction. In this contingency plan, 
the transaction document containing the payment instruction is configured into a 
proper telex format with a summary report for the user of the core transaction 
component 12 to generate the test codes. The telex is automatically transmitted to 
the bank. 

15 

If the query in step 98 is "Yes", the algorithm proceeds to step 100, where the 
IDOC statuses in the core transaction component 12 are changed to "13" with a 
message "Error while posting the payments" by using a SAP® RFC call to the core 
transaction component 12. In step 102, an email message is sent to the authorized 
20 users of the core transaction component 12 to manually release the transaction 
document via conventionally established telex transmission. The users executes 
transaction ZF0642 to view the statuses of the payment instructions released from 
the core transaction component 12 and produce a telex report for all payments with 
the status code "13". The telex report is displayed to the user where the test code is 
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calculated based on a confidential formula provided by the bank. Each bank uses a 
different formula. A separate report is prepared for each bank indicating all 
payments that failed. 

5 In step 104, the authorized users release the transaction documents via telex 

transmission to the host bank and the operation is completed. After a successful 
transmission, the user updates the IDOC status code to n 12", indicating that the 
payment was successfully acknowledged by bank. 

10 If the query of step 98 is "No," the algorithm proceeds to step 88 to begin 

reestablishment of the secure connection with the host bank server 20. 

Once the secure connection to the host bank server 20 is established in step 
90 and the query in step 92 is "Yes", the algorithm proceeds to step 105. In step 
15 105, the core interface component 14 delivers the transaction document containing 
the payment instructions and the digital signature through the global computer 
network 16 to the bank interface component 18 of the host bank server 20. The 
customer's bank 27 proceeds to carry out the payment transaction using its retail 
banking system as is known in the art. 

20 

In Figure 3C, the algorithm proceeds to step 106 where the core interface 
component 14 awaits from the bank interface component 18, in this example 
included with the server 20, a response document formatted in XML containing 
response status codes and messages for each of the payment instructions that were 
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posted to the bank. In step 108, the core interface component 14 receives the 
response document from the bank interface component 18. All the XML documents 
communicated between the bank and the customer are logged in the system of the 
present invention, and generally identified as "Document Sent" and "Document 
Received", respectively. In step 110, the return codes and messages of the 
response document are stored in the core interface database memory 36 in the form 
of a table referred herein as T_BC_DOCUMENT_RECEIVED for auditing purposes. 
The core interface component 14 processes the statuses in the response document 
for each of the payment instructions in step 112. The algorithm proceeds to step 
114, wherein the status of each payment instruction is determined by the core 
interface component. 

For return code "OK" in query step 114, the algorithm proceeds to step 116 
wherein the MT100 formatted payment instruction is determined to be accepted 
successfully by the host bank. The core interface component 14 then updates the 
IDOC statuses in the core transaction component 12 to "12" with a message 
"Payment successfully acknowledged by the bank" by using a SAP® RFC call to the 
core transaction component 12. A report listing successful payments can be 
generated using transaction "ZF0642" as will be described hereinafter. 

For return code "DE", "01° or "09" in query step 114, the algorithm proceeds to 
step 120 wherein the MT100 formatted payment instruction is determined to be 
invalid. The payment instruction contains a data validation error. The error is 
typically contained in the business data due to incorrect master data or profile 
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information inputted by the core transaction component 12. The algorithm proceeds 
to step 122. wherein the core interface component 14 updates the I DOC statuses in 
the core transaction component 14 to code "11" signaling the failure of payment 
acceptance by the bank due to validation. The algorithm proceeds to step 124 of 
Figure 3D. In step 124, the core interface component 14 sends email notification to 
the user of the core transaction component 14 with the appropriate error message 
from the bank. The algorithm proceeds to query step 126 wherein the validity of the 
rejection is determined. If the query is "No," the algorithm proceeds to step 128 
wherein the user of the core transaction component 12 initiates transactions 
"ZF0646" also referred to as a Payment Reversal Tool for setting the I DOC status to 
"31° and "ZF0642" for implementing payment status reporting, and payment 
instructions are submitted to the bank via telex transmission. In step 130, a telex 
acknowledgment is received from the bank as confirmation, and the operation of the 
system 10 is completed. 

If the rejection is determined to be valid in query step 126, the algorithm 
proceeds to step 132 wherein the user of the core transaction component 12 initiates 
transaction ZF0646 and reverses payment. In step 134, the user makes the 
necessary correction to the data that generated the error. In step 136, the corrected 
payment instruction is reentered into the core transaction component 12 wherein the 
algorithm proceeds back to step 50 of Figure 3A. 

Referring back to Figure 3C, for return code "Failed" in query step 114, the 
algorithm proceeds to step 138 wherein the service or component at the host bank 
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server 20 is determined to have failed. The algorithm proceeds to step 140 wherein 
the return code is treated as a technical failure on the bank side, and wherein the 
core interface component 14 updates the IDOC statuses in the core transaction 
component 14 to code "13" with the message "Error while posting the payment 

5 instruction" signaling the failure of payment acceptance by the bank due to technical 
problems. The algorithm proceeds to step 142 of Figure 3E. In step 142, the core 
interface component 14 sends an email notification to the user of the core 
transaction component 12 along with the reason for payment rejection due to 
technical difficulties. The algorithm proceeds to step 144 wherein the user of the 

10 core transaction component 12 initiates transaction "ZF0642" for payment reporting, 
and payment instructions are submitted to the bank via telex transmission. In step 
146, a telex acknowledgment is received from the bank as confirmation, and the 
operation of the system 1 0 is completed. 

15 Referring back to Figure 3C, for return code "DUDE" or "DUOK" in query step 

114, the algorithm proceeds to step 148 or step 150, respectively, wherein the 
payment instruction is determined to be a duplicate. The "DUDE" return code is 
returned by the bank for payments that were rejected with a DE error. The "DUOK" 
return code is returned by the bank server 20 for payments accepted in a previous 

20 transmission. In either of the steps 148 or 150, the algorithm proceeds to step 152 
of Figure 3F. In query step 152, the core interface component 14 determines 
whether the return code is "DUDE" or DUOK". If the return code is "DUDE", the 
algorithm proceeds to step 154 where the core interface component 14 checks the 
last IDOC status of the payment instruction in the core transaction component 12. In 
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query step 156, the core interface component 14 determines whether the status 
code is "11" or payment rejected by bank. If the query is "No," then the algorithm 
proceeds to step 124 of Figure 3D. If the query is "Yes," the algorithm proceeds to 
step 158 wherein the core interface component 14 sends an email notification to the 
5 technical personnel for troubleshooting why the payment was posted again, and the 
operation of the system 10 is completed. 



In query step 152, if the return code is "DUOK", the algorithm proceeds to 
step 160 where the where the core interface component 14 checks the last I DOC 

10 status of the payment instruction in the core transaction component 12. In query 
step 162, the core interface component 14 determines whether the status code is 
"12" or payment successfully acknowledged by bank. If the query is "No", then the 
algorithm proceeds to step 164 where the core interface component 14 updates the 
IDOC statuses in the core transaction component 14 to code "12" with the message 

15 ^payment successfully acknowledged by bank". The operation of system 10 is 
completed. 



In query step 162, if the answer is "Yes", then the algorithm proceeds to step 
166, in which the core interface component 14 sends an email notification to the 
users of the core transaction component 12 and the technical personnel that a 
payment was duplicated and corrective action is to be taken. The operation of the 
system 10 is completed. 
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It is noted that the payment instructions transmitted to the host bank server 20 
should not be repaired automatically by the bank interface component 18 if errors 
are present All payment instructions with errors are returned to the core interface 
component 14 with a detail message and return codes. 

5 

The core interface component 14 can be configured to generate a payment 
advice report for all successful payments (i.e., status code n 12 B ) using transaction 
"ZF0642". 

10 Referring to Figure 4, a flowchart detailing the operation of the system 10 is 

shown for another mode of operation and embodiment of the invention. Bank 
statements are typically retrieved once a day after banking hours and at an agreed 
upon time for automatic reconciliation. Typically, the time would be in the early 
morning on the next day. Data received from the bank contains information as to the 

15 nature of each transaction in the bank statement. For example, a transaction code is 
indicated to show, for example, a check payment transaction, an electronic payment 
a bank transfer or a customer receipt. 

Reference information (e.g., check number, reference number) relative to 
20 each item can also be included in the bank statement. Based on the information 
contained in the bank statement, all outstanding transactions stored in the core 
transaction component 12 can automatically be cleared when reconciled. The 
electronic bank statement is received and converted into a format recognizable by 
the core transaction component 12 by the core interface component 14. 
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In step 168, the core transaction component 12 initiates a statement request 
which is sent to the core interface component 14. In step 170, the core interface 
component 14 receives the statement request and converts it into an XML 

5 document In step 172, core interface component 14 retrieves the requirement 
parameters from the EBANKING.CNG configuration file to establish a secure socket 
layer (SSL) session through the global computer network 16. A secure connection to 
the host bank server 20 via the bank interface component 18 is established in step 
180. The algorithm proceeds to query step 182 to determine whether a connection 

10 was successfully established. If the query is "No", then the algorithm proceeds to 
query step 174 to determine if the number of tries is greater than three. If the query 
is "No", the algorithm proceeds back to step 180. If the query in query step 174 is 
"Yes", the algorithm proceeds to step 176 where the core interface component 14 
sends an email notification to the user of the core transaction component 12 and 

15 technical personnel to alert them of a connection problem. In step 178, the core 
interface component 14 raises a "Failure" exception to the core transaction 
component 12 to manually reinitiate the statement request. 

If a successful connection is established, the algorithm proceeds to step 184 
20 where the XML statement request is posted by the core interface component 14 of 
the interface server 25 to the host bank server 20 via the global computer network 
16. The host bank server 20 sends a request response containing the bank 
statement to the associated bank interface component 18 where the statement, an 
MT940 statement, is converted into XML, and then forwarded to the core interface 
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component 14 via the global computer network 16 in step 186. In step 188, the core 
interface component 14 stores the statement request and request response in the 
core interface database 36 in the form of a table referred herein as 
T_BCJDOCUMENT_SENT and T_BC_DOCUMENT_RECEIVED, respectively, for 
5 auditing purposes. In step 190, the bank statement formatted in MT940 in 
accordance with SWIFT standard is extracted from the request response and stored 
in the core transaction component 12. In step 192, the core transaction component 
12 imports the data contained in the bank statement to reconcile the transactions. 
The operation of the system 10 is completed. 

10 

Referring to Figure 5, a flowchart detailing the operation of the system 1 0 is 
shown for another mode of operation, and for another embodiment of the invention. 
Online bank statement access is provided for the user, via computer 32 in this 
example, in the present invention for viewing statements in real-time directly from the 

15 host bank server 20. The statement viewing access is provided only for viewing 
purposes and not for reconciliation. In step 194, in response to a user request, the 
core transaction component 12 initiates a statement request through transaction 
"ZF0640 0 also referred to as an On-line Statement Report Tool for viewing online 
bank statements. In step 196, the core interface component 14 receives the 

20 statement request and formats the request into an XML document In step 198, the 
core interface component 14 retrieves the bank specific requirements to establish a 
SSL connection with the host bank server 20 via the global computer network 16. 
Attempts to establish a secure connection is made in step 200. In query step 202, 
the core interface component 14 determines whether a secure connection has been 



27 



WO 2004/025430 PCT/US2003/029551 

established. If the query is B No D , the algorithm proceeds to step 204 where a return 
connection error message corresponding to the °ZF0640 n function is displayed to the 
requesting user and the operation of the system 10 is completed. 

If the query in query step 202 is "Yes", the algorithm proceeds to step 206 
where the statement request containing statement request parameters is posted to 
the bank interface component 18. The bank interface component 18 processes the 
statement request for upload to the host bank server 20. The host bank server 20 
generates a bank statement in the format of SWIFT MT940 to the bank interface 
component 18. The bank interface component 18 converts the bank statement into 
an XML format and transmits it to the core interface component 14. In step 208, the 
core interface component 14 receives the bank statement. In step 210, the core 
interface component 14 processes the MT940 data from the bank statement into a 
structured output and uploads the output to the core transaction component 12 for 
display to the user. 

Although various embodiments of the invention have been shown and 
described in detail above, they are not meant to be limiting. Those of skill in the art 
may recognize certain modifications to these embodiments, which modifications are 
20 meant to be covered by the appended claims. For example, although a global 
computer network 16, such as the Internet is illustrated for providing a data 
connection path, or link between a customer's local server 21 and the bank's server 
20, the network 16 can also be a local area network (LAN) for communicating within 
a large building where the customer and their bank is located, or a wide area 
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network (WAN) where the customer and their bank is located in a common business 
park, for example. 
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